Feel free to hijack this PR for any exploration as long as you coordinate with anyone, I opened this to foster discussion.

Adjacently-related to Darwin issues that @piegamesde reported.

Does that mean that you are fine with breakages of your packages for architectures outside of this list ?

Does that mean that you are fine with breakages of your packages for architectures outside of this list ?

I'd say, it communicates more that I cannot really commit to anything outside of this list. Not a lot of people can commit to fix a package for the Knuth architecture anyway on a daily basis.

Other than that, how are you thinking of using this?

The first use I see is that if something is broken on macOS and has a less-active maintainer with macOS as primary, one can try @-mention them in some useful and descriptive way, otherwise it goes to platform team (with lower expectations of success)

I like the general idea! Though just adding such entries doesn't really do very much, it needs to come with something that actually uses them. For example if we had email notifications working for broken Hydra builds this would interact really nicely with this. Other than that, how are you thinking of using this?

Actually, even the existence of those entries can go quite far to inform maintainers to what to expect from other fellow maintainers, without any automation. Plus, step one, is getting the metadata right before writing any automation, IMHO.

This is a classical problem in nixpkgs contribution when someone is blocked on a PR because they do not have Darwin machines, and they cannot fix the problem at hand that CI says "this is broken", sometimes, this can also end up being a rabbit hole in Darwin internals because someone does not know how to fix it.

To give a clear example, I do not expect any x86_64-linux maintainer to know a fair deal about how macOS frameworks work, though, sometimes when there is a breakage, you have to fix it using that knowledge.

Moving forward, as a release manager, I need to be able to understand if I can rely on someone to fix something for a specific supported architecture, sometimes, it is not possible to find a Darwin or aarch64 maintainer for something, this field would help me to ping the right people.

Moving forward again, OfBorg can eat this metadata, nix-eval-jobs can eat this metadata, this can help to detect brittleness when it comes to maintenance, etc. For ZHF, this can further improve the list generation of maintainers to avoid listing people who won't be able to produce any effort towards a specific architecture breakage.

I like it; it's moving in the right direction. This will become more useful once the tooling takes it into account, but it's a chicken-and-egg problem.

I think this idea is interesting. I'm simply afraid that some people will interpret it as a moral pass to disregard other architecture. I still think that whenever merging a change breaks an architecture for a package, it is wished that the maintainer does it best to see if the breakage can be fixed.

A push that maintainers should do more about platforms they don't care about is a push towards maintainers actively opposing adding platforms.

a moral pass to disregard other architecture

Sometimes I feel inclined to disregard other architecture when this other architecture is Darwin spending 20 days on ofBorg.

This is going to make these things more explicit. We're all hoping for goodwill, but we can't force people to maintain architectures they don't control.

Now that we kind of agree on the intents and goals, I think, we need to discuss how to enrich the existing data.

My idea is that we will have folks who won't be able to declare their "primary/available" architectures, therefore, we will have a period of incomplete metadata. Though, we need to coordinate pinging everyone to add their metadata somehow.

I believe we only need to design the way to add yourself in the lists, I don't know if we want to have denormalized or normalized lists for that, e.g. a list of maintainers per platform primary/available, a maintainer that contains a list of architectures. Open to ideas here.

Once we get the design right, fix the type checking, add a script to know who is missing for the metadata (i.e. a maintainer with no primary platform), we can have a mergeable prototype IMHO?

Then, I would suggest we can open up work on exploiting the metadata, be it for ZHF, or our own PR automation, etc.

Would this plan make sense to you, folks?

Here, I suggest what architectures I commit to maintain for my own packages.

I'd imagine that people would want to define this per package. Some package groups are easily maintained cross platform and others are very hard to.

Here, I suggest what architectures I commit to maintain for my own packages.

I'd imagine that people would want to define this per package. Some package groups are easily maintained cross platform and others are very hard to.

This seems overkill for the first design. The metadata is not supposed to reflect perfect information.

Some package groups are easily maintained cross platform and others are very hard to.

Erm, if a package is easy to maintain on a platform where you cannot even run it to test, that sounds like the platform list for maintainers will never be looked up because it will work or break on all platforms together?

Sure, there are some exotic cases, but I guess we can start with putting comments in the relevant packages, and once there are examples, they can be considered for v2.